A computer network includes computer processors or “hosts” that host software applications that provide or request services, or both. The hosts may be network terminals or end stations that do not perform network traffic routing or forwarding functions. The hosts communicate with each other through network devices, such as switches and routers, sometimes called intermediate devices, which do perform routing and forwarding functions. When a host is added to a network by connecting directly to another host, or indirectly to another host through one or more intermediate devices, the host must be configured for network operations. For example, the newly added host is assigned a logical network address for itself, and a network address for the intermediate device that routes or forwards its traffic, among other configuration information.
Computer networks that employ the Transmission Control Protocol and Internet Protocol (TCP/IP) for sending packets of information between devices on the network are proliferating, and as a result, logical network addresses that are used to locate each device on the network have become scarce. Further, in many local networks with many different computers, the number and location of the computers connected to the network may change regularly. In addition, of the many computers physically connected at one time, only a fraction of the computers are on and operating at one time. Thus one or more hosts are being added and dropped frequently.
A specific context in which this problem arises involves large-scale cable modem networks in which voice and other services are delivered over an Internet Protocol network that uses coaxial cable for communications. Addresses are dynamically assigned to cable modems of end users as the users subscribe to and terminate use of service, and to devices that cannot persistently store an address. In this context, it is wasteful to give every device a unique and permanent network address. A number of addresses sufficient for the total anticipated subscriber base can be shared, but configuring each host with a new address is a tedious process to perform manually.
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism through which computers using TCP/IP can obtain network addresses and other configuration information automatically. DHCP is an open standard protocol for dynamic host configuration described in request for comments (RFC) documents numbered 2131 and 2132 available at the time of this writing as rfc2131.txt and rfc2132.txt, respectively, on the worldwide web (www) at domain and directory ietf.org/rfc/. A DHCP server process operates on a DHCP server host that is conveniently located for several hosts on one or more local networks. One or more DHCP server hosts and processes are set up by a system administrator with information to configure the hosts on one or more local networks to reflect the current architecture of those local networks. A DHCP client process operates on each host of the local networks. As used hereinafter, a server refers to the server process and a client refers to the client process unless otherwise indicated to refer to the host or device on which the process executes.
When a host begins operations on the local network, the DHCP client on that host requests configuration information from one of the DHCP servers. In response to the request from the DHCP client, one or more of the DHCP servers respond with configuration information to be used by the host of the DHCP client for a predetermined period of time (“lease time”), including an IP address for the host of the DHCP client. Such responses take the form of “offers” of data. The DHCP client notifies the servers that one of the offers is accepted. The host that is executing the DHCP client then uses the configuration information including the address. The configuration information is bound to the particular DHCP client, and the binding is recorded by the DHCP server that offered it.
At a first time, t1, when a substantial portion of the lease time has passed, the DHCP client sends a renewal request to the DHCP server indicating that the lease time should be extended. For example a renewal request may be sent when 75% of the lease time has elapsed. If the DHCP server of the accepted offer does not receive a renewal request from the DHCP client within the lease time, the DHCP server is free to offer that configuration information and IP address to another DHCP client after the lease time expires. If the DHCP client does not receive a response from the DHCP server to a renewal request by a second time, t2, after t1, when almost all of the lease time has passed, such as 95%, the DHCP client sends a rebinding request to all the DHCP servers to provide a new lease for the IP address the DHCP client is currently using.
A DHCP relay agent is a process that executes on an intermediate device to forward DHCP messages between DHCP client and DHCP server. The DHCP relay agent facilitates communications with the DHCP client before the DHCP client's host is bound to a particular IP address. The DHCP relay agent is used when the DHCP client cannot broadcast directly to the DHCP server because it is separated from that DHCP server by network routing elements. In this case, the DHCP relay agent on the router closest to DHCP client receives a broadcast to port 67 and then forwards the DHCP client's packet on to all DHCP server for which it is configured. In this way, the DHCP client can broadcast locally and still make contact with one or more DHCP servers.
A problem arises with the exchange of messages described above in circumstances in which the DHCP client and the DHCP servers cannot communicate directly. In such circumstances an intermediate device, such as a router, prevents direct communication between the DHCP client and the DHCP server. If either the DHCP client or DHCP server wishes to send information to the other, the sender directs the information in a message to the intermediate device and the intermediate device determines that the information is appropriate for sending to the other or not. In some circumstances, the intermediate device may alter the information in the original message, such as by adding to or deleting from the information in the original message, and send the altered message to the other. As used herein, when an intermediate device prevents direct communication, or receives and reviews information in a message in order to determine whether to forward the message, or alters information in the message, or performs any combination of these actions, the intermediate device is said to filter the communication. An example circumstance in which an intermediate device filters communications among hosts is when the intermediate device enforces some security policy, such as for a firewall. In some circumstances, hardware problems on a wire, interface, or intermediate device can lead to special processing by another intermediate device that constitutes filtering as used herein. Also, an intermediate device filters traffic when a host is on a virtual private network. In virtual private networks, routers are configured to communicate traffic between certain network addresses only when the traffic is encrypted at the intermediate device that routes the traffic onto a public network such as the Internet. If the DHCP server host is not among the certain network addresses, the intermediate device prevents direct traffic.
In circumstances in which an intermediate device filters the communications, the intermediate device prevents the DHCP renewal message sent from a DHCP client to the particular DHCP server that provided the original lease. With renewal messages blocked, clients are forced into risking the validity of their configuration information. The client is routinely forced to rely on use of re-binding requests to carry out renewal in the last hours of the lease time, although the re-binding was designed only for unusual circumstances. If the DHCP servers are off-line for maintenance or for updating by the system administrator at the time a re-binding request is sent, or out of available IP addresses, the client will lose its IP address and be unable to maintain or establish communication with other hosts on the networks until a new IP address is obtained.
If a relay agent is properly configured, the initial DHCP request of a client is not affected, because the initial request is a broadcast not directed to a particular DHCP server. Initial requests normally are issued to a well-known port number, most often “67.” The intermediate device receives the broadcast, determines the value of the port from the message, recognizes it as a DHCP message if the port value is 67, and invokes the DHCP relay agent to handle the message. If the system administrator has made an exception for DHCP messages, e.g., allowing a host behind the firewall or on the VPN to use the local DHCP servers, the relay agent sends the message to the one or more local DHCP servers.
Direct communication messages that indicate a particular network address as a destination address are called unicasts. DCHP relay agents are not configured to check unicasts in which the intermediate device is not the destination, because doing so would severely impede network traffic through the intermediate device. Thus DHCP relay agents do not detect and process renewal requests because the renewal requests are unicasts addressed directly to the DHCP server that provided the configuration information bound to the DHCP client. It is not practical to implement an approach that has the relay agent inspect every unicast passing through the intermediate device to detect DHCP messages; because such a approach would severely impede network performance.
In another approach, the DHCP client could be modified to send renewal requests directly to the intermediate device. However, this approach is not practical because tens of millions of DHCP clients have already been deployed over the last decade without such a modification. It would be expensive and take many years to even replace a significant fraction of the deployed DHCP clients. In addition, a modification to the DHCP standard, as embodied in Internet Requests for Comment (RFCs), would be required. Such a change to the DHCP standard is not likely to be accepted, or if it is accepted, it would not be implemented quickly.
Based on the foregoing, there is a clear need for techniques that dynamically assign network addresses when communications between a client host and a server host are filtered by an intermediate network device, without modifying the client process.